When electronic data such as an electronic document is transmitted in the public key foundation in a public key infrastructure, a digital signature of a transmitter and a public key certificate issued by a certification authority are attached to electronic data which becomes an object. A receiver confirms that the transmitted electronic data is not falsified and the electronic data is certainly electronic data transmitted from the transmitter himself or herself by confirming the validity of the digital signature (hereafter referred to as “signature”) and the public key certificate attached to received data. Issuance of the public key certificate and confirmation of the validity are conducted in the public key infrastructure. And its standard specifications are stipulated in RFC 5280 (Internet X.509 Public Key Infrastructure Certificate and CRL Profile) and the like.
For example, in a case where there is a change in contents stated in a public key certificate before its term of validity expires, the public key certificate is revoked to become invalid by a certification authority that issued the public key certificate. In confirmation of validity of a received public key certificate, therefore, the receiver needs to certify whether the public key certificate is revoked.
For ascertaining whether the certificate is revoked, a public key certificate revocation list (hereafter referred to as “CRL”) issued by the certification authority is used. In the CRL, a name (issuerName) of the certification authority, key information (authorityKeyIdentifier) of the certification authority, a serial number (serialNumber) of a revoked public key certificate included in public key certificates in the term of validity issued by the certification authority, the term of validity of the CRL, and the like are stated. A signature of the certification authority is affixed to the CRL. The CRL is issued periodically by the certification authority. The serial number is information which is set to make it possible for a certification authority issuing public key certificates to uniquely identify a public key certificate issued by the certification authority itself. The receiver acquires the CRL from the certification authority and certifies whether a serial number of a public key certificate attached to received data is stated in the CRL. If the serial number is stated in the CRL, the receiver judges that this public key certificate is revoked and is invalid. If the serial number is not stated in the CRL, the receiver judges that this public key certificate is valid.
In a case where the number of public key certificates issued by the certification authority is large and a large number of public key certificates are revoked, however, the capacity of the CRL becomes enormous. This results in a problem that it takes a time for a receiver who wants to confirm validity of a public key certificate attached to received data to acquire the CRL and conduct validity confirmation processing of the public key certificate. In order to cope with this, there is a validation server which is service of accepting a request to ascertain whether a public key certificate is revoked on line and giving a response to the request. And as one form of the validation server, there is the OCSP (Online Certificate Status Protocol) responder which confirms a state of a public key certificate by using the CRL. Its standard specifications are stipulated in non patent literature 1.
The OCSP responder periodically takes in the CRL issued by the certification authority, and accepts a revocation confirmation request (hereafter referred to as “validation request”) of a public key certificate from a terminal (hereafter referred to as “terminal device”) used by a receiver who conducts revocation confirmation of the public key certificate. Information (hereafter referred to as “CertID”) for identifying a validation object certificate (a public key certificate of a validation object) is described in the validation request. A hash algorithm (hashAlgorithm) used by the terminal device, name information (issuerNameHash) of the certification authority that has issued the validation object certificate, key information (issuerKeyHash) of the certification authority, and a serial number (serialNumber) of the validation object certificate are included in the CertID. Among them, the name information of the certification authority and the key information of the certification authority are obtained by conducting a hash calculation on name data (issuerName) and key data (authorityKeyIdentifier) of the certification authority with a hash algorithm (hashAlgorithm) used by the terminal device.
Upon accepting a validation request, the OCSP responder checks whether the serial number of the validation object certificate is stated in the CRL previously taken in, and gives the terminal device a response as to whether the public key certificate which is this validation object certificate is revoked. In a response message (hereafter referred to as “response”) of a validation result transmitted from the OCSP responder to the terminal device, the state of the validation object certificate is stated as valid (good), revoked, or unknown. In addition, a signature (hereafter referred to as “response signature”) and a certificate (hereafter referred to as “OCSP certificate”) of the OCSP responder that has conducted the validation are attached to the response. As a result, the user of the terminal device can confirm that the response is certainly transmitted by this OCSP responder.
By the way, all serial numbers of public key certificates that have been revoked at the time when the certification authority makes the CRL are stated in the CRL.
Furthermore, if the certification authority conducts key update of a private key, signature is conducted by using an updated new key in a public key certificate and a CRL issued after the key update. As for a public key certificate issued by a certification authority before key update, a case where the validity cannot be confirmed even within the term of validity occurs. A technique concerning an OCSP responder that validates the validity of a public key certificate issued by a certification authority no matter whether it is before or after the key update and gives a response to the receiver in such a case is disclosed in patent literature 1.
In recent years, jeopardizing of some encryption algorithms caused by advance of cryptanalysis techniques and capability enhancement of computers is pointed out. In 2005, jeopardizing of a hash function SHA-1 used in signature was announced by NIST (National Institute of Standards and Technology), and a change of the encryption algorithm from the existing SHA-1 to SHA-2 was intensely recommended. Upon receiving this, certificate authorities in various countries make it their principles to change the encryption algorithm used for the public key of the user and signature of the public key certificate to an encryption algorithm having higher safety while maintaining compatibility with an information system utilizing the existing encryption algorithm. Such jeopardizing of the encryption algorithm occurs at some definite intervals with the advance of the technique.
The change of the encryption algorithm caused by jeopardizing of the encryption algorithm causes occurrence of situations where an encryption algorithm in use differs every validation object certificate, every user (hereafter referred to as “user”) who transmits a validation request to the OCSP responder, and every CRL issued by the certification authority. The OCSP responder needs to conduct validation even for a public key certificate using a signature according to an old encryption algorithm and a terminal device that copes with only an old encryption algorithm, and transmit a response. The OCSP needs to cope with a plurality of encryption algorithms.
Because of these situations, a selection method of the encryption algorithm for the response signature affixed to a validation result by the OCSP responder is under study in IETF (The Internet Engineering Task Force) which is a standardization drawing up organization as disclosed in non patent literature 2. In non patent literature 2, it is also possible for the user to set a PSA (Preferred Signature Algorithm), which is an encryption algorithm of a signature specified by the user, in a request extension (requestExtensions) area in a validation request and specify an encryption algorithm of a response signature affixed by the OCSP responder.